• 专利附录
  • 专利说明
  • 权利要求
  • 类似技术
  • 同族专利
  • 引用文献
  • 法律状态
  • 优先权
    • 专利摘要:
    A parking meter (2), comprising a video terminal (8), at least one peripheral device for inputting data (8, 7, 5), a payment card reader (6), a network communication terminal (10), and a control unit (100) which interfaces with the peripheral units of the parking meter, characterised by the fact that the control unit is configured to:- acquire a desired payment type (S1, S2, S3) inputted by a user and chosen from a list of preset types comprising at least one payment type other than parking payment (S2), and identify (CAPS) a purchaser code (cal, ca2, ca3,...) pre-associated with the payment type acquired (S1, S2, S3),- on the basis of the payment type acquired, enable a payment method (4, 6), and read the data required for the payment,- send a bank data processor (PG) the purchaser code (cal, ca2, ca3,...), the amount paid, and the data required for the payment, so that the bank data processor (PG):- checks the payment authorisation on the basis of the relevant data;- identifies, on the basis of the purchaser code (cal, ca2, ca3,...), an arrangement code (cc1, cc2, cc3,...) which is univocally associated with a single bank account (C1, C2, C3,...) and- instructs a payment service provider (A) to credit the amount paid to the bank account (C1, C2, C3,...) associated with the arrangement code (cc1, cc2, cc3,...), and- once the transaction has been completed successfully, the video terminal (8) displays a confirmation message that the transaction has been completed successfully and/or that a printer (3) has issued a receipt or a proof of entitlement following payment.
    公开号:EP3680868A1
    申请号:EP19218454.7
    申请日:2019-12-20
    公开日:2020-07-15
    发明作者:Vezio MAGGIONI
    申请人:Flowbird Italia Srl；
    IPC主号:G06Q20-00
    专利说明:
    [0001] The present invention relates to a parking payment machine or parking meter and to a method for the operation thereof.
    [0002] In particular, it relates to a parking payment machine (commonly known as a "parking meter") whereby a user may pay (generally in advance) for parking within a designated vehicle parking zone. BACKGROUND ART
    [0003] As is known, over recent years, the parking meters have become extremely widespread nationally. This is mainly due to extensive regulation of paid parking implemented by many town and city councils and service providers.
    [0004] Nowadays, parking meters are somewhat sophisticated devices that comprise parking payment means which are more than simply coin collection units. Indeed, over recent years, it has become increasingly common to pay for parking using credit cards, prepaid cards, and payment services such as Fastpay and the like, and therefore parking meters have evolved accordingly in order to process also the aforesaid parking payment methods. SUMMARY OF THE INVENTION
    [0005] Object of the present invention is to provide a parking payment machine that is able to process different types of payments contemporaneously.
    [0006] A further object of the invention is to process different payment methods, directing each payment to a dedicated bank account.
    [0007] This and other objects are achieved by means of a parking payment machine according to the technical teachings of the claims annexed hereto. BRIEF DESCRIPTION OF THE FIGURES
    [0008] Further characteristics and advantages of the innovation will become clearer in the description of a preferred but not exclusive embodiment of the invention, illustrated - by way of a non-limiting example - in the sole drawing annexed hereto, which shows - schematically - a payment system using a parking payment machine. DETAILED DESCRIPTION OF THE INVENTION
    [0009] With reference to the figure stated, reference number 2 is used to denote, as a whole, a parking payment machine.
    [0010] The parking payment machine 2, or parking meter 2 (which may also be known by other names, such as parking payment device or parking payment station), comprises a frame firmly fixed to the ground, for example to the a pavement or at the side of the road, near a paid parking area.
    [0011] After parking their car (or other vehicle) in the parking area, a user goes to the parking meter 2 and proceeds by paying for the parking to the payment in advance, inserting coins into a collection unit 4 for the amount of time they intend to park. Upon reaching the desired amount, the user presses a button and a dedicated printer 3 prints out a parking ticket showing when the park time ends. The ticket must be displayed on the car dashboard so that it is clearly visible in the event of checks.
    [0012] The money paid for parking is appropriately stored inside the machine and collected at regular intervals by personnel of either the parking area owners or the concession holders (town/city council, transport company, etc).
    [0013] Advantageously, the machine 2 may also feature a display 8 (possibly of the touchscreen variety) for displaying the parking data.
    [0014] The machine may also feature a hardware keypad 7 for inputting, for example, the car license plate number or other relevant information. Obviously, the keyboard may also be of the virtual kind, integrated into the touchscreen.
    [0015] The parking payment machine 2 may also feature different payment means, apart from the coin collection unit 4.
    [0016] For example, the said machine may feature a payment card reader 6, which may be of the wireless kind and which may be associated with a conventional number pad 5 for keying in the card PIN (if necessary). Obviously, the number pad 5 may feature its own display unit.
    [0017] There may also be Fastpay payment system featured (allowing for the use of bank cards associated with the Fastpay circuit).
    [0018] For credit card payments, the machine 2 is equipped with a network communication terminal 10 for the connection to the Internet 200 (or to a private data network), the said terminal being designed to interface with a control unit 100 for controlling the said machine via the network. Preferably, the communication network 10 is a 3G/4G network terminal (or, in the future, a 4.5G or 5G network terminal), but it may also comprise a wired or wi-fi network interface, a data interface on a mobile telephone network, or another known data communication system, depending on the situation.
    [0019] More specifically, when parking needs to be paid for, after the reader 6 has read (possibly via a wireless method) the data on the payment card and has confirmed the payment amount, the control unit 100 communicates the data needed for the payment to the bank data processor PG (for example SIA s.p.a.) via the terminal 10. The bank data processor, via a payment service provider, proceeds by crediting the amount paid for the parking to the designated bank account.
    [0020] According to the present invention, the parking payment machine 2 allows the clients (parking service providers, local government, etc) to provide different kinds of services via parking meters (payment for parking or of fines, transport tickets ...), with different payment methods and payments credited to different bank accounts depending on the type of service provided.
    [0021] Regarding this, the control unit 100 (which interfaces with the peripheral units of the machine 2), is configured to: acquire a desired payment type S1, S2, S3 inputted by a user and chosen from a list of preset types comprising at least one payment type other than parking payment, and identify (CAPS) a purchaser code which is pre-associated with the payment type acquired S1, S2, S3.
    [0022] For example, the user may use the virtual (or hardware) keyboard to select a desired payment type.
    [0023] The preset payment types S1, S2, S3 may comprise payment for parking (S2), and one or more of the following types: payment of fines (S1), payment of taxes, payment of local taxes, payment for public transport tickets (S3), payment for services provided by local councils, payment of bills.
    [0024] Furthermore, on the basis of the payment type acquired (chosen, therefore, by the user), the control unit can enable a payment method 4, 6, and read the data required for the payment.
    [0025] For example, the control unit 100 may be programmed to accept payment of a fine (S1) by payment cards only, and not through the coin collection unit. Therefore, in the event that the user selects the fine payment option, only the card reader 6 will be enabled.
    [0026] The card data needed for the payment is then read (by the reader 6) .
    [0027] The optional data relating to fine (for example, fine number, payer's name etc) are inputted via either the touchscreen or the keyboard. Such data may also be inputted via other peripheral input units, such as, for example, a barcode reader, a QR code reader etc.
    [0028] Essentially, the control unit 100 acquires all the data relating to the payment to be made and the data of the card (or other payment system) needed to proceed therewith.
    [0029] Furthermore, each payment type S1, S2, S3, is associated (for example in the memory of the control unit 100, or in a database in network) with a purchaser code (ca1, ca2, ca3,...).
    [0030] After collecting all the information described above, the control unit 100 sends to a bank data processor PG (via the interface 10 for example) the purchaser code (ca1, ca2, ca3,...), the amount paid, and the data required for the payment, and -where envisaged - other optional data.
    [0031] In the event (as in the case set out above) of payment of a fine, which corresponds to payment type S1, the control unit sends the bank data processor PG the purchaser code ca1, together with the other payment data.
    [0032] The bank data processor PG therefore proceeds to: check the payment authorisation on the basis of the relevant data; identify - on the basis of the purchaser code received - an arrangement code (cc1, cc2, cc3,...) which is univocally associated with a single bank account (C1, C2, C3,...) and instruct a payment service provider (A) to credit the amount paid to the bank account (C1, C2, C3,...) associated with the arrangement code (cc1, cc2, cc3,...).
    [0033] In the example described, the purchaser code ca1 (for the payment of fines S1) corresponds to the arrangement code cc1, associated with the bank account C1, held with the bank B1.
    [0034] Obviously, the bank accounts associated with the different arrangement codes, may be held with different banks B1, B2, B3. Or various bank accounts C2, C3, may be held with the same bank B3. Each arrangement code (cc1, cc2, cc3) allows the system to direct the amount to a single bank account held with the desired bank.
    [0035] Once the transaction has been completed successfully, the video terminal 8 can display a confirmation message that the transaction has been completed successfully.
    [0036] It is also possible for a fine payment receipt to be printed out (or, in any case, a receipt for the transaction requested).
    [0037] The method described above is carried out in a similar way for other types of payments, such as, for example, payment for a transport public ticket (option S3).
    [0038] In this case, the control unit 100 will send the bank data processor PG a different purchaser code (ca3) from the previous one (linked to another arrangement code cc3 and therefore to another bank account, in other words bank account C3, held with bank B3) and, once the transaction has been completed, the printer 3 can print out a proof of entitlement, such as a ticket.
    [0039] In the example set out above, payment card is used for the payment, but obviously the machine 2 may feature other means, such as credit or debit cards, prepaid card, Fastpay circuit payment cards, etc.
    [0040] In Italy and in Europe, a bank data processor PG may be, for example, SIA s.p.a. while a payment service provider A may be, for example, Mercury/Bank Intesa.
    [0041] Advantageously, every single entity - for example the TOWN/CITY COUNCIL 1, may be assigned several purchaser codes ca1, ca2, ca,... and every purchaser code may refer to a different bank account C1, C2, C3 (including accounts held with different banks B1, B2, B3).
    [0042] For example, TOWN/CITY COUNCIL 1 may hold three bank accounts all in its own name. The three accounts may be, for example, C2 (assigned to car park payments), C1 (assigned to fine payments), C3 (assigned to the public transport ticket payments). For example, bank accounts C2 and C3 may both be held with the same bank B3.
    [0043] Each bank account is associated with an arrangement code (cc1, cc2, cc3) that refers to a purchaser code, for example: ca2 (town/city 1, car park payments, arrangement code cc2), ca1 (town/city 1, fine payments, arrangement code cc1), ca3 (town/city 1, public transport ticket payments, arrangement code cc3).
    [0044] Each purchaser code (ca1, ca2, ca3) refers to a different payment type (S1, S2, S3), connecting the payment type therefore to a different arrangement code (cc1, cc2, cc3) and therefore to a different bank account (C1, C2, C3).
    [0045] For example, payment option S1 (selectable by the user for the payment of fines) refers to purchaser code ca1, which is connected to arrangement code cc1 and therefore to bank account C1.
    [0046] Payment option S2 (for parking payments) refers to purchaser code ca2, which is connected to arrangement code cc2, and therefore linked to bank account C2 held with bank B3.
    [0047] Payment option S3 (for public transport ticket payments) refers to purchaser code ca3, which is connected to arrangement code cc3 and therefore linked to bank account C3, held with bank B3, and so on.
    [0048] It has been shown that a parking payment machine such as that described here is able to allow a sum to be automatically credited to a bank account dedicated to payments for services other than just parking.
    [0049] Various embodiments of the innovation have been disclosed herein, but further embodiments may also be conceived using the same innovative concept.
    权利要求:
    Claims (10)
    [0001] A parking meter (2), comprising a video terminal (8), at least one peripheral device for inputting data (8, 7, 5), a payment card reader (6), a network communication terminal (10), and a control unit (100) which interfaces with the peripheral units of the parking meter (2), characterised by the fact that the control unit is configured to:
    - acquire a desired payment type (S1, S2, S3) inputted by a user and chosen from a list of preset types comprising at least one payment type other than parking payment (S2) and identify (CAPS) a purchaser code (ca1, ca2, ca3,...) pre-associated with the payment type acquired (S1, S2, S3),
    - on the basis of the payment type acquired, enable a payment method (4, 6), and read the data required for the payment,
    - send to a bank data processor (PG) the purchaser code (ca1, ca2, ca3,...), the amount paid, and the data required for the payment, so that the bank data processor (PG):
    - checks the payment authorisation on the basis of the relevant data;
    - identifies, on the basis of the purchaser code (ca1, ca2, ca3,...), an arrangement code (cc1, cc2, cc3,...) which is univocally associated with a single bank account (C1, C2, C3,...) and
    - instructs a payment service provider (A) to credit the amount paid to the bank account (C1, C2, C3,...) associated with the arrangement code (cc1, cc2, cc3,...), and
    - once the transaction has been completed successfully, the video terminal (8) displays a confirmation message that the transaction has been completed successfully and/or that a printer (3) has issued a receipt or a proof of entitlement following payment.
    [0002] A parking meter (2) according to Claim 1, wherein the payment method comprises one or more of the following payments means: payment card, credit card, debit card, prepaid card, Fastpay.
    [0003] A parking meter (2) according to Claim 1, wherein the payment service provider (A) comprises Mercury/Bank Intesa and/or SIA-Fastpay, and/or wherein the bank data processor (PG) comprises SIA S.p.a.
    [0004] A parking meter (2) according to Claim 1, wherein the receipt or the entitlement is a public transport ticket and/or a receipt for payment of a fine, and/or a receipt for the payment of a tax.
    [0005] A parking meter (2) according to Claim 1, wherein an individual entity may be assigned several purchaser codes (ca1, ca2, ca3,...), each one of which is associated with a different bank account, the bank accounts associated with the purchaser codes assigned to the said individual entity being preferably held in the name of the said individual entity.
    [0006] A parking meter (2) according to Claim 1, wherein the preset payment types (S1, S2, S3) comprise at least payment for parking (S2), and one or more of the following types: payment of fines (S1), payment of taxes, payment of local taxes, payment for public transport tickets (S3), payment for local services, payment of bills.
    [0007] A parking meter (2) according to Claim 1, wherein the peripheral device for inputting data (8, 7, 5) comprises one or more of the following devices: a touchscreen, a number pad, a keyboard.
    [0008] A parking meter (2) according to Claim 1, wherein the payment card reader (6) comprises a wireless reading system.
    [0009] A parking meter (2) according to Claim 1, wherein the network communication terminal (10) comprises a wired and/or wi-fi network interface and/or a data interface based on a mobile telephone network.
    [0010] A method for the operation of a parking meter (2), comprising a video terminal (8), at least one peripheral device for inputting data (8, 7, 5), a payment card reader (6), a network communication terminal (10), and a control unit (100) which interfaces with the peripheral units of the parking meter (2), characterised by the fact that the control unit is configured to:
    - acquire a desired payment type (S1, S2, S3) inputted by a user and chosen from a list of preset types comprising at least one payment type other than parking payment (S2), and identify (CAPS) a purchaser code (ca1, ca2, ca3,...) pre-associated with the payment type acquired (S1, S2, S3),
    - on the basis of the payment type acquired, enable a payment method (4, 6), and read the data required for the payment,
    - send a bank data processor (PG) the purchaser code (ca1, ca2, ca3,...), the amount paid, and the data required for the payment, so that the bank data processor (PG):
    - checks the payment authorisation on the basis of the relevant data;
    - identifies, on the basis of the purchaser code (ca1, ca2, ca3,...), an arrangement code (cc1, cc2, cc3,...) which is univocally associated with a single bank account (C1, C2, C3,...) and
    - instructs a payment service provider (A) to credit the amount paid to the bank account (C1, C2, C3,...) associated with the arrangement code (cc1, cc2, cc3,...), and
    - once the transaction has been completed successfully, the video terminal (8) displays a confirmation message that the transaction has been completed successfully and/or that a printer (3) has issued a receipt or a proof of entitlement following payment.
    类似技术:
    公开号 | 公开日 | 专利标题
    US10915887B2|2021-02-09|System and method for electronic prepaid account replenishment
    US20170323282A1|2017-11-09|Methods and systems for exchanging and/or transferring various forms of value
    US20170330168A1|2017-11-16|Method and portable apparatus for settling transaction
    AU2012308618B2|2017-09-21|Fuel dispensing environment utilizing mobile payment
    US8131640B2|2012-03-06|Method for receiving electronically transferred funds using an automated teller machine
    AU775640B2|2004-08-12|Vending machine purchase via cellular telephone
    US6032859A|2000-03-07|Method for processing debit purchase transactions using a counter-top terminal system
    AU2003211085B2|2008-06-12|Methods and systems for exchanging and/or transferring various forms of value
    US8271335B2|2012-09-18|Mobile communication terminal and method for electronic money settlement
    DE69821992T2|2005-01-05|SYSTEM AND METHOD FOR CONTROLLING FINANCIAL TRANSFERS THROUGH A WIRELESS NETWORK
    US6038552A|2000-03-14|Method and apparatus to process combined credit and debit card transactions
    US6081792A|2000-06-27|ATM and POS terminal and method of use thereof
    EP1756776B1|2012-07-11|System for and method of automating parking payment by using electronic tags
    US6364206B1|2002-04-02|Lottery ticket sales in fueling forecourt
    CA2264048C|2006-03-21|Automatic electronic funds transfer system and method
    US7686210B2|2010-03-30|Stored-value education account
    US20130339227A1|2013-12-19|Method and apparatus for money transfer
    AU687142B2|1998-02-19|System and method for conducting cashless transactions
    US7021530B2|2006-04-04|System and method for managing and processing stored-value cards and bill payment therefrom
    US6766949B2|2004-07-27|Cash back during dispenser transaction
    EP0634039B1|1998-02-04|Parking system
    US20130046587A1|2013-02-21|System and method for managing parking rights
    US6816721B1|2004-11-09|System and method of purchasing products and services using prepaid wireless communications services account
    US6823317B1|2004-11-23|Urban parking system
    AU695518B2|1998-08-13|Methods and apparatus for providing a prepaid, remote entry customer account
    同族专利:
    公开号 | 公开日
    IT201900000406A1|2020-07-10|
    引用文献:
    公开号 | 申请日 | 公开日 | 申请人 | 专利标题
    法律状态:
    2020-06-12| STAA| Information on the status of an ep patent application or granted ep patent|Free format text: STATUS: THE APPLICATION HAS BEEN PUBLISHED |
    2020-06-12| PUAI| Public reference made under article 153(3) epc to a published international application that has entered the european phase|Free format text: ORIGINAL CODE: 0009012 |
    2020-07-15| AK| Designated contracting states|Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
    2020-07-15| AX| Request for extension of the european patent|Extension state: BA ME |
    2021-01-15| STAA| Information on the status of an ep patent application or granted ep patent|Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
    2021-02-17| RBV| Designated contracting states (corrected)|Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
    2021-02-17| 17P| Request for examination filed|Effective date: 20210107 |
    优先权:
    申请号 | 申请日 | 专利标题
    [返回顶部]